The present invention is related to programming non-volatile memory, and more particularly to methods and apparatus for programming electrically erasable non-volatile memory using a Universal Serial Bus (USB) interface.
USB is fast becoming the defacto bus interface standard for low to medium speed personal computer (PC) to peripheral device interconnections. The USB interface achieves transport speeds that are fast enough for supporting high-speed printers, CD-quality audio playback, and high-resolution scanners. USB expansion hubs make the bus available for supporting dozens of USB capable devices simultaneously. Detailed information regarding USB functionality and capabilities may found in the Universal Serial Bus Specification, Revision 2.0 (Apr. 27, 2000).
USB has gained popularity for several reasons. First, a USB device can be plugged into the bus at anytime, even when the PC is turned on; a feature commonly referred to in industry as xe2x80x9cplug-n-playxe2x80x9d. When the PC detects that a USB device has been plugged in, the PC automatically interrogates the device to learn its capabilities and requirements. Using this information, the PC then automatically loads the device""s driver into the operating system. Later, when the device is unplugged from the bus, the operating system automatically xe2x80x9clogs offxe2x80x9d the device from the bus, and unloads its driver from the system.
Another reason for the growing popularity of the USB interface is that the built-in plug-n-play capability eliminates the need to manually set DIP switches, insert jumpers, or load configuration programs, in order to properly configure devices attached to the bus. Also, USB connected devices do not result in the hardware conflicts (e.g., IRQ, DMA, MEMORY, or I/O conflicts) that commonly occur when connecting devices to today""s conventional serial and parallel I/O buses.
USB devices are sold with internally stored software (or firmware) that controls the operation of the device. This firmware is typically stored in non-volatile, electrically erasable, programmable memory, such as the popular flash memory developed by Intel Corporation. Users that have purchased USB capable devices may occasionally require the ability to upgrade this firmware with improved versions, or with firmware patches, as such upgrades become available from the device manufacturers.
These firmware upgrades may be effected in several ways. For example, if the firmware is stored on a separate memory module in the device, the module may be removed from the device and replaced with a new memory module that includes the firmware updates. This manual upgrade method has the disadvantages of being both difficult and time consuming to perform, as well as typically requiring that the device be powered off to effect the upgrade. Also, this manual method requires the firmware to be stored on a dedicated memory module within the device, which may lead to inefficient use of memory in the device.
An easier and more efficient method of upgrading the firmware installed in a peripheral device has been to use an existing device I/O bus to upgrade the firmware code. With this method, either the entire firmware program may be first erased, and then overwritten with the new firmware code, or only a portion of the originally installed firmware may be overwritten with a corresponding firmware xe2x80x9cpatchxe2x80x9d.
Alternatively, the hardware may be so configured so as to allow firmware patches to be installed in specially reserved portions of the system memory, and then automatically executed under certain program conditions to effect a firmware upgrade. Such an arrangement is described in copending U.S. patent application Ser. No. 09/896,780, entitled xe2x80x9cMethod and Apparatus for Dynamically Modifying a Stored Programxe2x80x9d, assigned to the same assignee as this application.
To use an existing I/O bus to upgrade the firmware code stored in device, it is first necessary to develop a transfer protocol that controls and oversees the firmware upgrade process. Generally, a different transfer protocol must be developed for each corresponding I/O bus type used to upgrade the firmware.
In the case of USB, a transfer protocol for effecting firmware upgrades in USB capable devices has been proposed by the USB Implementors Forum (USB-IF). This group has published a document for its proposed transfer protocol entitled xe2x80x9cUniversal Serial Bus Device Class Specification for Device Firmware Upgradexe2x80x9d, Version 1.0, May 13, 1999. This document describes proposed requirements and specifications for implementing USB devices that are capable of supporting the group""s proposed Device Firmware Upgrade (DFU) function.
A drawback of the proposed DFU solution is that concurrent execution of both DFU operations and normal run-time activities is not possible within the USB device. The proposed specification requires that all normal run-time activities must cease for the duration of any DFU (upgrade) operations. This implementation thus requires that a device re-enumerate, or change its operating mode, to effect a firmware upgrade. For example, according to the proposed specification, a printer would not function as a printer while undergoing a firmware upgrade. Instead, the printer would be operating as a firmware programmer during DFU operations. This is due, at least in part, to the fact that under the DFU proposal, only a single endpoint (or channel) is active between the programming host and the USB device. Typically, re-enumeration requires that the device be physically disconnected from the USB bus. In contrast, the techniques described below employ several endpoints between the host and USB device to maintain normal device operations, even while the device firmware is being programmed or updated.
The type of memory programming described in the DFU proposal is referred to as xe2x80x9cin-circuitxe2x80x9d programming. While the memory need not be removed from its circuitry, the device nevertheless no longer operates in its normal mode during the programming phase. In-circuit programming is to be contrasted with in-system programming (a feature of the techniques described herein), in which a device continues to operate (at least partially) in its normal mode of operation during the programming process. Another important advantage to programming device firmware in-system is that host device drivers, used to communicate with the device during its operation, need not be uninstalled while the firmware is being programmed, and then reinstalled when the programming process has ended. Not having to uninstall then reinstall device drivers saves time and host system resources.
Others have approached the problem of effecting firmware upgrades in USB devices in an entirely different manner. For example, Cypress Semiconductor offers a solution called xe2x80x9cEZ-USBxe2x80x9d, that includes an internal microprocessor and internal random access memory (RAM) for program and data storage in the USB device itself. The use of volatile RAM to store the device firmware, rather the non-volatile memory used in other USB devices, makes the EZ-USB product a so-called xe2x80x9csoft solutionxe2x80x9d product. During normal operation, a USB host (e.g., the PC) may initiate a download of program instructions into the device internal microprocessor, and device xe2x80x9cpersonalityxe2x80x9d firmware into the device internal RAM over the USB bus. After the download completes, the EZ-USB device is reconnected to the PC as a newly customized device defined by the downloaded personality firmware.
Although this solution does provide for the ability to download new firmware over a USB interface at any time during device operation, the solution nevertheless has some drawbacks. First, because the firmware is stored in RAM instead of some other form of non-volatile memory, the firmware will be lost should power to the device ever be inadvertently disconnected during operation. Firmware loss may also occur if the device is mistakenly disconnected from the USB interface in bus-powered devices. Second, whenever a firmware download is initiated by the PC host, the EZ-USB device must first be disconnected from the host when the download completes, and then be reconnected (or re-enumerated as it commonly referred to as) by the host before the upgraded device may be used in its new configuration. This limitation deprives the user of the ability to utilize the device during firmware upgrades.
Accordingly, there is a need for a solution to both quickly and easily update the firmware stored in memory of a USB device.
To address those needs, Applicants have invented certain methods and apparatus for programming non-volatile, programmable, electrically-erasable memory using a USB interface. According to one aspect, a method for in-system programming of non-volatile, programmable, electrically erasable device memory using a USB interface is presented, the method including the steps of: enumerating at least one device onto a USB bus with a first hardware configuration; encapsulating programming commands and program data into USB packets according to a custom protocol; sending the USB packets including the encapsulated programming commands and program data to the at least one device over the USB bus; and programming at least a portion of the device memory in response to receiving the programming commands and program data at the at least one device. At least partial functionality of the at least one device as defined by the first hardware configuration is maintained while the device memory is programmed.
According to a related aspect, the method further includes the steps of: changing at least partially the first hardware configuration of the at least one device in response to receiving a first programming command at the at least one device; loading at least one of a plurality control functions of a code module stored in a portion of the device memory into RAM; executing the at least one control function from RAM using the programming commands and program data received at the at least one device to program the device memory; and restoring the hardware configuration of the device back to the first hardware configuration in response to receiving a second programming command at the at least one device after the device memory is programmed.
According to another related aspect, the code module includes at least: a main loop function for managing the processing of programming commands sent over the USB bus; a packet exchange function for transferring USB packets over the USB bus; a vendor request function for encapsulating/extracting programming commands and program data into/from the USB packets according to the custom protocol; an erase function for erasing information stored in the at least a portion of the device memory; a write function for writing program data extracted from the USB packets by the vendor request function to the at least a portion of the device memory; and a read function for reading program information stored in the at least a portion of the device memory.
According to yet another related aspect, the method further includes the steps of: disabling interrupts associated with the first hardware configuration in response to receiving the first programming command; copying an interrupt vector table for processing interrupts associated with the first hardware configuration to RAM; and enabling interrupts associated with the first hardware configuration to be processed from RAM.
According to yet another related aspect, the method further includes the step of: erasing information stored in the at least a portion of the device memory prior to the programming step in response to receiving a third programming command at the at least one device. The step of erasing information stored in the at least a portion of the device memory the steps of: determining the location and size of the at least a portion of the device memory to be erased from information included in the third programming command; loading an erase function stored in a portion of the device memory into RAM; executing the erase function from RAM to erase the information stored in the at least a portion of the device memory; and sending status information over the USB bus upon completion of the erasing of the information stored in the at least a portion of the device memory.
According to yet another related aspect, the method further includes the step of: reading information stored in the at least a portion of the device memory after the programming step in response to receiving a fourth programming command at the at least one device. The step of reading information stored in the at least a portion of the device memory includes the steps of: determining the location and size of the at least a portion of the device memory to be read from information included in the fourth programming command; loading a read function stored in a portion of the device memory into RAM; executing the read function from RAM to read the information stored in the at least a portion of the device memory and to send the read information over the USB bus; and sending status information over the USB bus upon completion of the reading and sending of the information stored in the at least a portion of the device memory.
According to yet another related aspect, the method further includes the steps of: verifying the information read from the at least a portion of the device memory to determine if the information is properly programmed into the device memory; and reprogramming information into the at least a portion of the device memory determined to be invalid in the verifying step. The step of programming the at least a portion of the device memory includes the steps of: determining the location and size of the at least a portion of the device memory to be programed from information included in the programming commands; receiving the program data sent over the USB bus into a RAM buffer until one of the RAM buffer is full and no more program data is received; loading a program data function stored in a portion of the device memory into RAM; executing the program data function from RAM to store the received program data into the at least a portion of the device memory; repeating the steps of receiving program data and executing the program data function when the RAM buffer is full and additional program data remains to be stored in the device memory; and sending status information over the USB bus upon completion of the storing of the program data into the at least a portion of the device memory.
According to yet another related aspect, the method further includes the steps of: enumerating multiple USB devices onto the USB bus, each with a respective first hardware configuration; and controlling the flow of programming commands and program data sent over the USB bus to each of the devices enumerated onto the USB bus to manage the simultaneous programming of at least a portion of the device memory included in each respective device.
According to yet another related aspect, a plurality of endpoints are used to exchange information encapsulated into USB packets according to the custom protocol over the USB bus, the endpoints including: a control endpoint for exchanging USB packets having encapsulated programming commands; a bulk endpoint having a bulk IN channel for sending USB packets having encapsulated program data to the at least one device and a bulk OUT channel for sending USB packets having encapsulated program data from the at least one device over the USB bus; and an interrupt IN endpoint for sending USB packets having encapsulated status information from the at least one device over the USB bus.
According to yet another related aspect, information encapsulated into USB packets according to the custom protocol and exchanged over the USB bus includes information stored in: a request type field; a request identifier field; a request value field; a data field; a data length fields; and an address index field.
According to yet another related aspect, the information stored in the request type field is one of a standard type request, a class type request, and a vendor type request. If the information stored in the request type field is a vendor type request, the information stored in the request identifier field includes one of at least an erase request, a device memory write request, a device memory read request, a check_id request, a get_device_info request, a RAM read request, a RAM write request, and a jump-to-function request.
It should be emphasized that the terms xe2x80x9ccomprisesxe2x80x9d and xe2x80x9ccomprisingxe2x80x9d, when used in this specification as well as in the claims, are taken to specify the presence of stated features, steps or components; but the use of these terms does not preclude the presence or addition of one or more other features, steps, components or groups thereof.